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VMEbus Implementation Summary 



This document is intended to provide customers of Sun Microsystems with all 
the information needed to attach devices to the Sun-3/100 VMEbus, including 
programming and hardware design considerations. It is not intended to explain 
to VMEbus perse, as it assumes a working knowledge that can be derived from 
studying the VMEbus Specification, available from Motorola Semiconductor Pro- 
ducts, Inc. 



Table 1-1 Master Capabilities 



Data Bus Size: 
Address Bus Size: 

Timeout Option: 

Sequential Access: 
Interrupt Handler: 



Requestor Option: 
Bus Busy Option: 
Read/Modify/Write: 



D32 MASTER 32/16/8 bit data 

A32 MASTER (DYN) 32/24/16 bit 
addresses 

TOUT (737) 737 microsecond 
timeout period 

None 

IH(1-7)(STAT) Level 1 thru 7. 
independently jumpcrablc. All 
interrupts use vectors provided by 
VMEbus interrupters, per the VME 
spec. 

ROR R(3) Release On Request, 
level 3 

Releases BBSY after AS assertion 
when releasing bus 

Will not release VMEbus during 
read/modify /write cycles. RMW 
instructions must not be used while 
DVMA is occurring, as the 68020 
.will not relinquish and retry on 
deadlocks during RMW cycles and 
cause timeout bus errors. 



NOTE Address strobe is negated between the read and write portions ofRW cycles, .v.) 
the Sun-3/100 does not use RMW cycles as defined in the VMEbus Specification 
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Table 1-2 Slave Capabilities 



Data Bus Size: 
Address Bus Size: 

Sequential Access: 
Special Access Mode: 



Interrupter Options: 
32-bit Slave Addressing: 



24-bit Slave Addressing: 



D32 SLAVE (DYN) 32/16/8 bit data 
A32 SLAVE (DYN)32/24 bit 
addresses (no 16-bit addresses) 

None 

A high-speed access mode (Lock 
Mode) is engaged if the time from 
DTACK assertion to the next AS &. 
DS assertion is less than 200ns 
None 

The Sun-3/100 responds to the bot- 
tom 1 MB by performing DVMA 
using system function codes and 
responds to the top 2 GB by per- 
forming DVMA using user function 
codes. Response can by dynamically 
disabled on 256 MB boundaries. 
The Sun-3/100 responds to the bot- 
tom Mb by performing DVMA 
using system function codes. 



Table 1-3 System Controller Capabilities 



Clock Option: 


SYSCLK 16 MHz, 
jumperable (not used 
onboard) 


Arbiter Option: 


ONE bus request/grant 
level 3 only - or external 




arbiter 


Bus Timeout Module: 


None 


Sysreset Option: 


SYSRESET MASTER or 
SYSRESET SLAVE, incl. 




manual button 


AC Fail Option: 


Not implemented 
(ACFAIL is connected to 




SYSRESET) 
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Table 1-4 Environmental Characteristics 



Operating Temperature: 
Humidity: 



10 - 40 deg C 

5 - 90% non-condensing 



Table 1-5 Power Considerations 



+5 Volts: 


14 Amp maximum 


-S Volts: 


1 Amp maximum 


+12 Volts: 


0.5 Amp maximum 


-12 Volts: 


Not used 



Table 1-6 Typical Sun-3/J00 Performance Parameters 



Parameter 


Sun-2 


Sun-3/100 Measured 


Notes 


CPU to VME Latency 1 


468 ns 


381ns 


1 


CPU to VME Latency 2 


264 ns 


186 ns 


2 


CPU to VME Bandwidth 


3.3 MB/sec 


9.5 MB/sec 


3 




606 ns 


420 ns 




VME to P2 Latency 


952 ns 


743 ns 


4 




1020 ns 


510ns 




VME to P2 Bandwidth 


1.97 MB/sec 


7.84 MB/sec 


5 


Time to Acquire VME 


162-264 ns 


141-191 ns 


6 


CPU-to-CPU Bandwidth 




3.44 MB/sec 
1163 ns 


7 


UNIX Throughput 


310KB/scc 


704 KB/sec 


8 


Astraca Bd. Throughput 




2.8 MB/scc 


9 


Xylogics Throughput 




1.41 MB/scc 
1420 ns 


10 


GP Cycle Time 




1200 ns 


11 


Lock Mode Throughput 




600 ns 
6.67 MB/scc 


12 


Lock Mode Latency 




440 ns 


13 



NOTE Unless otherwise noted, the Sun-2 numbers are estimates for a Sun-2'50 worksta- 
tion. 

The following numbered notes give more detail on the parameters from the tabic 
above and arc referenced bv ihe column, "Notes.'" 
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1. Measured from processor address strobe to vme DTACK with an ideal vme 
device, with the CPU not currently bus master. Unless otherwise noted, 
measurements are the average of 10 samples on a logic analyzer with a 10 ns 
resolution. 

2. Measured same as above, but CPU currently bus master. 

3. Assumes an ideal 32-bit data vme device. 

4. Measured from VME address strobe to VME DTACK. 

5. Assumes P2 bus is locked, allowing a 65 ns negation period on vme address 
strobe. The Sun-3/100 measured number is extrapolated from actual meas- 
ured data, as we currently do not have VMEbus masters this fast 

6. Measured from assertion of vme bus request to assertion of vme bus grant. 

7. One Sun-3/100 is not fast enough to engage lock mode on a second Sun- 
3/100. The estimated number is derived from analysis of the schematic. 

8. Command used is cp filename /dev/null, file size is 10 MB. Both disks were 
Fujitsu Eagles; disk controllers were Xylogics, with the Sun-3/100 using a 
VME-Multibus adapter. The Sun-2 was a 2/120 system. 

9. The Astraea board is a 256 KB memory board with a response time from 
VME DTACK of 279 ns. Test was a hand-assembled tight loop writing over 
the VMEbus to the Astraea board. The estimated number is from analysis of 
the schematic, combined with the information about the response time of the 
Astraea board. 

10. Estimated from observation of oscilloscope traces. There were four distinct 
cycle times: 1300, 1400, 1500. and 1600 ns. Transfers were from disk to 
onboard memory. 

1 1 . Graphics processor (GP1 ) as Master and Sun-3/1 00 as Slave. 

12. Using graphics processor modified to automatically start a cycle 60 ns after 
ending previous cycle. 

13. Measured from vme address strobe to DTACK. 
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Latency 



2 1 Latency Latency, in this case, is the time elapsed between when an external vme master 

Considerations requests a cycle and when the Sun-3/100 board responds to that cycle. This 

latency can be divided into four separate periods: 

□ The time required to get control of the local bus from the current mas- 
ter. 

o The time required to get control of the local bus from the CPU; 

a The time required to perform any pending DMA of higher priority; 

o The time required to perform the cycle. 

The VMEbus has no specified time that a master may keep control of the bus after 
another master has issued a bus request, but the Sun-3/100 will release the bus as 
soon as it completes the cycle that may be in progress when the bus request 
arrives. The worse-case situation is when the bus request arrives just after state 3 
of a CPU access of the VMEbus, because at that point, it is committed to perform a 
vme cycle. At state 5 it will assert vme address strobe; at state 7 it will be syn- 
chronized; and at state 9 it will assert vme bus grant — for a total worst-case 
elapsed time of 232 nanoseconds. Masters other than the Sun-3/100 board may 
keep control of the bus for an arbitrary length of time. One example is the Xylo- 
gics disk controller board, which has been observed to keep control of the bus for 
over 45 microseconds after bus request has been asserted. 

The external master is now required to wait until the vme address strobe is 
negated before it can take control of the VMEbus, which can only happen after the 
currently addressed slave responds with vme DTACK. The VMEbus has no 
specified maximum response time either, so this can be an indeterminate period. 
In a Sun system the worst case response time is that of the Xylogics disk con- 
troller board, which can take up to 70 microseconds. 

Once the vme address strobe goes away, the external master can take control of 
the VMEbus, enable its addresses and data onto the bus. and assert its own address 
and data strobes. These addresses and strobes arc decoded on the Sun-3/100 
board to form an onboard request called XREQ. 

The worst-case time to acquire the local bus is when XREQ arrives just as the CPU 
starts a cycle to a slow onboard device such as an interrupt acknowledge to the 
vectored serial ports, which takes up to 1 170 nanoseconds. This time will add to 
the lime required to decode the VMEbus addresses and generate XREQ. which is 
1 80 nanoseconds if the vme address strobe exactly misses a CPL' synchronization 
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clock, for a total of 1350 nanoseconds. 

If sometime during that 1 170 nanoseconds when waiting for the local bus, a DMA 
request from the Ethernet interface is received, it win be serviced first This will 
require approximately 500 nanoseconds to complete, during which a refresh 
request might be received. The latter request will require another 300 
nanoseconds and may give the Ethernet interface enough time to turn around and 
request another DMA cycle, giving another 500 nanosecond delay. At this point, 
the VME slave cycle is assured of service. Thus, the total worst- case wait to 
acquire the local bus is 2.65 microseconds. 

The final component of the Sun-3/100 slave response time is the actual time 
needed to perform the memory cycle and generate a vme DTACK, which in the 
case of a main memory cycle is 330 nanoseconds. Therefore, the total time, 
under the absolute worst-case conditions, to acquire the VMEbus and perform a 
memory cycle on the Sun-3/100 board is 3.21 microseconds, not counting the 
time required for a board that may currently be master to finish its cycles and 
relinquish the VMEbus. 
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Throughput Considerations 



3.1. Lock Mode 



Lock Mode prevents the CPU from using its local bus and is engaged when the 
turnaround time of the external vme master is less than 200 nanoseconds from 
when the Sun- 3/1 00 board asserts vme DTACK to when the external master 
asserts vme address and data strobes for the next cycle. As long as this situation 
occurs at the end of each slave cycle, the CPU local bus will remain locked for 
another cycle. 

During Lock Mode, refresh and Ethernet DMA cycles will continue to occur, as 
they have a higher priority than pending vme slave cycles. In addition, the CPU 
will be allowed to perform one bus cycle after each refresh if it necessary, so it 
can continue to limp along even if the Lock circuitry becomes defective, or if an 
external master keeps Lock Mode engaged for a long time. 

If a vme master device is designed specifically to use Lock Mode, it is preferable 
that it limit Lock Mode transfers to 16 in a row and then back off long enough to 
allow the CPU to perform a cycle. This is not a requirement, however, as generic 
boards might be able to engage Lock Mode. The 200 nanosecond figure is also a 
worst-case figure; for example, if the turnaround time is less than 200 
nanoseconds. Lock Mode is guaranteed to become engaged. If turnaround lime 
is between 200 and 240 nanoseconds. Lock Mode might be engaged. Lock Mode 
transfers arc shown in Figures 3-1 and 3-2. 



3.2. Throughput Lost to 
Ethernet 



The throughput number given above assumes no Eihcmct activity. If the Ether- 
net interface is attempting to perform DMA cycles at the same time as the vme 
slave interface, the slave interface will slow down. The Eihcmct operates at 10 
megabits/second, or 1.25 megabytes/second and takes an additional 10<?f for 
overhead such as fetching command blocks, buffer descriptors, anu so on. for a 
total bandwidth requirement of 1.37 megabytes/second. Subtract 1.37 
MB/scconds directly from the 7.84 MB/sccond figure provided in Tabic 1-6 for a 
figure of 6.46 MB/scconds through the vme slave interface when Ethernet is 
active. 



3.3. Throughput Lost to 
CPU and Refresh 



A refresh cycle is performed every 15 microseconds, taking approximately 300 
nanoseconds away from the time available for the vme slave interface. This 
represents a 2% overhead, for a loss of 0.16 MB/sccond. In addition, as men- 
tioned above, the CPU is allowed to perform one bus cycle after ever.' refresh 
cycle. If it takes advantage of this opportunity, the cycle will take 270 
nanoseconds. Four clocks will be wasted in turning mastership of the bus over to 
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the CPU and regaining it after the cycle, for a total loss of 5 10 nanoseconds. This 
3 4% overhead adds to the time taken for the actual refresh cycle of 2%, giving 
an overhead of 5.4%, or 0.42 MB/seconds. To a first approximation, this loss is 
additive to the Ethernet loss described in the previous section, so that the worst- 
case throughput of the VME slave interface is 6.04 MB/second, when Ethernet is 
active over a long period. 

3 4 Throughput Lost to In reference to note #5 from the table. Typical Sun-3/I00 Performance Parame- 

Turnaround Time ters, the master is allowed a 65 nanosecond negation period on the VME strobe. 

If the negation period is longer, performance will suffer in increments of 60 
nanoseconds per cycle, up to the point where the turnaround time is so slow that 
Lock Mode is no longer engaged. At that point, the CPU will start performing a 
memory cycle after each VME slave cycle, so two kinds of overhead will be 
incurred: the first is due to the actual time taken to perform the CPU cycle, and the 
second is due to time wasted in transferring the local bus back and forth between 
masters. This overhead amounts to 6.5 clocks, lowering the throughput from 
7.84 MB/seconds to 4.17 MB/seconds. See Figure 3-3. 
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Figure 3-1 Lock Mode Engagement 
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Total "window" for engaging Lock Mode is 5 clocks, or 300 ns. 
From this we must subtract several propagation delays, 
so that only 200 ns is left for the specified period from 
our assertion of VMEDtack to their assertion of VME 
Address Strobe and at least one VME Data Strobe. 



Lock Mode Engagement 
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Figure 3-2 VME Device Initiates P2 Bus Lock 
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Figure 3-3 VME Device Not Fast Enoush to Initiate P2 Bus Lock. 
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Timins 



The Sun-3/100 implements the full Motorola VMEbus Specification, Revision B, 
with no exceptions. Any board designed to meet the VME spec should plug right 
in. Nevertheless, in this section we provide the minimum/maximum timings for 
all signals on the VMEbus in both master and slave modes. See also Figure 4-1, 
which accompanies Table 4-1 — Master Timing and Figure 4-2, which accom- 
panies Table 4-2 — Slave Timing . 



Table 4- 1 Master Timing 



VME Spec # 


Description 


Min (ns) 


Max (ns) 


VME Spec (ns) 


1R 


Axx and AMx valid to AS* low 


38 


82 


38 


2R 


DTACK low to invalid address 


137 


7 





3R 


AS* high 


188 


7 


40 


4R 


DTACK low to AS* highf 


137 


294 





5R 


AS* to DS "A" skew 


7 


30 





6R 


WRITE* valid to DS "A" low 


38 


82 


35 


7R 


DS "B" high to invalid WRITE* 


10 


? 


10 


8R 


DATA release to DS "A" low 


150 


7 





9R 


DS"A"toDS"B"skew 





8 


10 


9W 


Dxx valid to DS "A" low 


38 


97 


35 


10R 


DTACK* low to DS "A" highf 


137 


244 





10W 


DTACK* low to invalid data 


137 


227 





11R 


DS"A"high 


168 


7 


40 


12R 


DS"B"toDS"A"low 


168 


7 


40 


13R 


DTACK*/BERR* high to DS "A" low 15 


7 





14R 


DTACK* low to DS "B" high* 


137 


244 





16R 


DS "B"high 


168 


7 


40 



+IT DTACK arrives wiihin 2.88 microseconds: otherwise m«=2560 



tSce 4R in above lablc. 
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Figure 4- 1 Master Timing: Write Cycle Followed By Read Cycle 
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Table 4-2 Slave Timing 



VMESpec# 



Description 



15W DS "A" low to DTACK*/BERR* low 

16R Data valid to DTACK* low 

18R DS "A" high to invalid data 

20R DS "B" high to DTACK*/BERR* high 



Min (ns) Max (ns) VME Spec (ns) 



352 


2980 


65 


125 


17 


67 


12 


50 



30 
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Figure 4-2 Data Transfer, Bus Slave Read Cycle 
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4.1. VME Arbiter and 
Requestor 



42. Master Addressing 



The Arbiter/Requestor is a synchronous state machine responsible for granting 
control of the VMEbus to the CPU while holding off other devices wishing control 
of the VMEbus and to grant control of the VMEbus to external vme devices when 
the CPU doesn't wish to to access it. The arbiter and requestor functions could be 
implemented as separate modules, but this was not done since separating the 
functions introduces extra states into the request process, slowing it significantly 
and increasing the chip count 

The arbitration function can be locked out by moving jumper J2701 to J2700, in 
case you wish the function to be performed on a separate board. You can install 
two or more Sun-3/100 boards in the same system for testing. Moving this 
jumper leaves the board operating only as a VMEbus requestor, as described in the 
VMEbus manual. 

During master cycles the addresses presented on the VMEbus are physical — the 
addresses have already been translated by the Memory Management Unit. Two 
bits called type and type 1 come out of the MMU to differentiate whether a 
given physical address is on the CPU board or on the VMEbus. If it is on the 
VMEbus, the bits tell you whether it is in the 16 or 32-bit data space. Note that 
the type and 1 bits give four complete 4 gigabyte address spaces: 

a Onboard memory; 

o Onboard input/output devices; 

a 1 6-bit data VME devices; 

a 32-bit data VME devices. 

Address space is further expanded by decoding separate CPU space, control space, 
and device space. However, all physical addresses reside in the device space. 

Accesses to the 32-bit data space will only be performed as vme long-word 
accesses if the address is long-word aligned, and the size of the cycle is long- 
word, as indicated by the 68020-sizc bits. Olhcrwiscthe cycle will be broken 
down into the appropriate number of byte and word accesses to the proper 
addresses, using the dynamic bus-sizing feature of the 68020. The vme 
Specification, Revision C was generalized to allow non-aligned 3-byte transfers. 
but the Sun-3/100 board docs not use this feature. 

Both of the vme spaces arc further decoded to handle devices that respond only 
to 16-bit addresses, or the full 32-bit addresses. The top 16 megabytes of each 
address space is reserved for 24-bit address devices, except for the top 64 kilo- 
bytes, which is reserved for 16-bit address devices. This allows the Sun-3/100 
board to access devices designed to use any combination of data and address 
widths. The number of address bits valid for the current cycle is indicated by ihc 
VME address modifiers, whik the width of the data transfer is indicated by the 
VME LWORD signal and data strobes, as discussed in the VME Specification. 

The address map described above is shown in Figure 4-3. 
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Figure 4-3 Physical Address Mapping 
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4.3. Long Master Cycles If the response time of a vme slave device is longer than 2.88 microseconds, the 

Sun-3/100 board can react slower to a DTACK from the slave, due to the way the 
Sun-3/100 board allows for long response times from vme slaves. Since the vme 
specification has no limit on the response time, it is necessary to implement a 
reasonable maximum. The difficulty is that main memory refresh cycles and the 
Ethernet interface operate under real-time constraints, so they must not be forgot- 
ten during long vme cycles. After 2.88 microseconds, the Sun-3/100 board 
assumes that the addressed device is very slow and only comes back periodically 
to check whether a response has been received from the device. Meanwhile, any 
pending refreshes or Ethernet cycles are performed. 
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Address Modifiers 



5.L Address Modifiers on 
Master Cycles 



The address modifiers on the VMEbus provide additional information about the 
nature of the cycle, such as the number of valid address bits and the type of pro- 
tection that should be applied to the current cycle. The Sun-3/100 implements 
the address modifiers as shown in the following table: 



Table 5- 1 Address Modifier Codes 



Address 
Modifier 
543210 



Function 



Hex 
Code 



10 1 32-bit addressing — user data space 09 

010 10 32-bit addressing — user program space 0A 

1 10 1 32-bit addressing — supervisor data space OD 

1110 32-bit addressing — supervisor program space OE 

10 1001 16-bit addressing — user data space 29 

10 1010 16-bit addressing — user program space 2A 

10 110 1 16-bit addressing — supervisor data space 2D 

10 1110 16-bit addressing — supervisor program space 2E 

1110 1 24-bit addressing — user data space 39 

1110 10 24-bit addressing — user program space 3A 

11110 1 24-bit addressing — supervisor data space 3D 

111110 24-bit addressing — supervisor program space 3E 



5.2. Slave Addressing 



The slave interface on the Sun-3/100 board has two operating modes, known as 
Supervisor DVMA and UscrDVMA.. Direct Virtual Memory Access is Sun's tra- 
demarked method of allowing DMA devices to use virtual addrcssscs instead of 
the usual physical addrcsscs.'saving software and hardware from the overhead of 
translating the addresses separately for the DMA devices. The virtual addresses 
from the VMEbus arc translated by the Sun-3/100 MMU into physical addresses. 
just like the addresses from the CPU. 

Supervisor DVMA corresponds to that which was available on the Sun-Z CP'J 
boards: a one megabyte window inio virtual memory, with DMA performed by 
using supervisor function codes. User DMA is an cxicnsion. new 10 the Sun-3/100 
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architecture, and allows VME devices to access the entire 256 megabyte virtual 
address space of the CPU in each of the eight contexts. Programs running on the 
CPU can share pointers to data at arbitrary locations with coprocessors located on 
the VMEbus, greatly simplifying the task of sharing data between the two proces- 
sors. Supervisor DVMA is performed if the address on the VMEbus is in the bot- 
tom megabyte of either the 24 or 32-bit VME address space, and if the Supervisor 
DVMA Enable bit in the System Enable Register is high. If the enable bit is low, 
the Sun-3/100 board will not respond. The board makes no distinction between 
Supervisor DVMA in 24-bit and 32-bit address spaces. 

The Sun-3/100 board responds in UserDVMA mode to VME addresses in the top 2 
gigabytes of the VME 32-bit address space, which requires VME address bit 31 to 
be high. User Dvma is performed with user function codes, so that it occurs with 
the full protection of the memory management unit. VME address bits 28-30 
correspond to the context bits; when address bits are all low, context is 
addressed. Contexts are individually enabled by bits in the UserDVMA Enable 
Register. If the context corresponding to the address currently on the VMEbus is 
not enabled, the Sun-3/100 board will not respond. Up to eight of the CPU boards 
may share the same backplane as long as only one context is enabled on each 
board. 

Slave address mapping is shown in Figure 5-1. 
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Figure 5- 1 VMEbus Slave Address Mapping 
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5.3. VME Option Jumpers 



Interrupts 



The seven levels of interrupts from the VMEbus are individually jumperable, sub- 
ject to the VME Specification requirement that an Interrupt Handler Module must 
respond only to a contiguous range of interrupt levels. ■ The jumper that handles 
interrupt levels is J300, located at coordinate R-5 on the CPU board, shown in 
Figure 5-3. A level is enabled when the jumper is installed. 

The Sun-3/100 board can also be jumpered to be the VME reset slave, instead of 
the master, as is default. At the factory, the CPU is jumpered as the vme arbiter 
and requestor, but you can change the setting to vme requestor only. These func- 
tions are controlled by jumpers J270O-27O3 at location R-12, shown in Figure 5- 
2. 

In order to insert more than one Sun-3/100 board into the same backplane, the 
VME clock driver must be disabled in all but one of them. This function is 
enabled by jumper J2502, at A-3, shown in Figure 5-2. 

For further information about jumper options, consult the Sun 3004 CPU Board 
Configuration Procedures, P/N 813-2047. 
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Figure 5-2 A-H Section of the 501-1208 Board 
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Figure 5-3 H-T Section of the 501-1208 Board 
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More Timing Diagrams 



Figure A- 1 CPU Access of Idle VMEbus 
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Figure A-2 CPU Access of VMEbus 
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Figure A-3 VME Device Acquires VMEbus and Accesses P2 Bus 
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USER'S GUIDE TO THE SUN-3/100 
VMEBUS READERS COMMENT 

SHEET 

Dear Reader, 

We who work at Sun Microsystems wish to provide the best possible documenta- 
tion for our products. To this end, we solicit your comments on the User's Guide 
to the Sun-3/100 VMEbus. We would appreciate your telling us about errors in 
the content of the manual, and about any material that you feel should be there 
but isn't. 

Please list typographical errors by page number and actual text of the error. 



Technical Errors 



Please list errors in technical accuracy by page number and actual text of the 
error. 
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Content 



Did this guide meet your needs? If not, please indicate what you think should be 
added or deleted in order to do so. Please comment on any material that you feel 
should be present but is not. Is there material found in other manuals that would 
be more .convenient if it were in this manual? 



Layout and Style 



Did you find the organization of this guide useful? If not, how would you rear- 
range things? Do you find the style of this manual pleasing or irritating? What 
would you like to see different? 



Mail this completed form to: 



Manager, Hardware Technical Publications 
Sun Microsystems, Inc. 
2550 Garcia Avenue 
Mountain View, CA 94043 



